Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-014.txt

Text File | 1992-11-18 | 33.6 KB | 931 lines | [TEXT/MPS ]

C.S.M.P. Digest             Wed, 11 Mar 92       Volume 1 : Issue 14

Today's Topics:

    Accessing individual objects in Think C 5.0.2
    Public domain word format???
    SndStartFilePlay snippet fails, help requested
    Classics And Double Buffered Sounds
    Fast Graphics (Non-Quickdraw)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Andrew Greenshields)
Subject: Accessing individual objects in Think C 5.0.2
Date: 8 Feb 92 16:43:03 GMT
Organization: Widener University Department of Computer Science, Chester PA


  I am gradually overcoming the problems I am having in writing my
first real Mac application thanks to the many experts on the net who
have given me invaluable assistance.

  I have another question for you all.  My program needs to draw
several identical objects on the screen and then manipulate them
individually.  Each one of these objects has a unique 'label' or ID
which distinguishes it from the others.  I am using the CPane class
for these objects so I can easily intercept clicks in them.  What I
need to know is there any way I can access them individually other
than clicking on them

  I had thought about putting them in a linked list, but I wasn't sure
if there was a method that already existed that did what I needed.

Thanks!

--
Andrew J. Greenshields N3IGS |     "It looks like the top part fell on
[e-mail]     |        the bottom part." - Dan Quayle
[e-mail]        |    ****** STANDARD DISCLAIMERS APPLY ******
===============================================================================



- -------------------------

From: [e-mail] (Bernie Bernstein)
Subject:  Accessing individual objects in Think C 5.0.2
Date: 10 Feb 92 19:03:03 GMT
Organization: University of Colorado, Boulder

In article <[e-mail]> [e-mail] (Andrew Greenshields) writes:
>  I have another question for you all.  My program needs to draw
>several identical objects on the screen and then manipulate them
>individually.  Each one of these objects has a unique 'label' or ID
>which distinguishes it from the others.  I am using the CPane class
>for these objects so I can easily intercept clicks in them.  What I
>need to know is there any way I can access them individually other
>than clicking on them
>
>  I had thought about putting them in a linked list, but I wasn't sure
>if there was a method that already existed that did what I needed.
>


Every view has a variable 'itsSubviews' which contains the views
within the view. So if you have the pane which encloses the objects
(which can be found in 'itsEnclosure'), you may traverse its subviews
and perform some operation on the objects. Another way to find the
pane if it is the main pane for a document is from the CDocument
'itsMainPane' variable.

So, lets say we have a pane, 'bigPane', which contains some subviews
that we need to traverse, and we want to set the value of my pane's
(of type 'CMyPane') variable 'myVar' to something.

...
bigPane = myDoc->itsMainPane;
if (bigPane->itsSubviews)
     bigPane->itsSubviews->DoForEach1(Change_My_Var, 10L);
...


void Change_My_Var(CView *aView, long newValue)
{
     if (member(aView, CMyPane))
          ((CMyPane*)aView)->myVar = newValue;
}

>Thanks!
>
>Andrew J. Greenshields N3IGS |     "It looks like the top part fell on
>[e-mail]     |        the bottom part." - Dan Quayle
>[e-mail]        |    ****** STANDARD DISCLAIMERS APPLY ******

Your welcome.
--
      o,  ,,   ,      | Bernie Bernstein                      | ,    ,,
      L>O/  \,/ \    ,| University of Colorado at boulder     |/ \,,/  \
     O./  '  / . `, / | office: [phone]                |     / ` \  ,.
    ,/   /  ,      '  | email: [e-mail]        | /        ''  \



---------------------------

From: [e-mail] (Mike  Mansell)
Subject: Public domain word format???
Date: 9 Feb 92 20:14:49 GMT
Organization: University of Victoria, Victoria, BC, Canada


    I'm looking for a non-propreitary format for transmitting
word-processing documents and pictures. I'm also looking for some code
to print these documents. Now, if I can use the code to print but
the format is propreitary, maybe.
    I've seen a format called Interchange RTF. Does anybody
know anything about this format? Is MacWrite format public?
    I need to be able to save data in a database which can
then be translated back into the orignal document. This data has
tobe able to contain pictures (PICT format).
    I don't know if there is anything available but
if
there is, could someone please let me know.
Thanks.

                        Michael Mansell
                        Computer Engineering
                        University of Victoria
                        [e-mail]



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Public domain word format???
Date: 10 Feb 92 05:02:22 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Mike  Mansell) writes:
>
>
>     I'm looking for a non-propreitary format for transmitting
> word-processing documents and pictures. I'm also looking for some code
> to print these documents. Now, if I can use the code to print but
> the format is propreitary, maybe.
>     I've seen a format called Interchange RTF. Does anybody
> know anything about this format? Is MacWrite format public?

Don't know if there are any other real standards than ODA,
and boy Mac applications would certainly be big and slow if
the apps would use ODA (it's one of these OSI/ISO buzzword
standards).

I would recommend to stick to RTF until something better comes
along.

Kent Sandvik



- -------------------------

From: [e-mail] (Stephen Uitti)
Subject:  Public domain word format???
Date: 10 Feb 92 15:23:03 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <[e-mail]> [e-mail] (Mike  Mansell) writes:
>    I'm looking for a non-propreitary format for transmitting
>word-processing documents and pictures. I'm also looking for some code
>to print these documents. Now, if I can use the code to print but
>the format is propreitary, maybe.
>    I've seen a format called Interchange RTF. Does anybody
>know anything about this format? Is MacWrite format public?

    Microsoft's Rich Text Format (RTF) is publicly available.
Last spring, I called Microsoft & they sent me a copy of the spec
for free.  There is also an on-line discussion of how to read
RTF, more or less.  I could probably find a copy & send it.
It's plain text, as I recall.

    RTF handles styled text, formatting, and graphics.  It
uses a text based approach for everything.

    I wrote an RTF reader in about two months.  RTF writting
would be much easier to do.  RTF does not appear to handle draw
style pictures - that is objects.  It has color or black & white
bitmaps.

    If you needed to add some feature to RTF, that only you
needed to read, it could be done easily.  RTF appears to be
extensible.

Stephen.
[e-mail]



---------------------------

From: [e-mail] (Peter Newton)
Subject: SndStartFilePlay snippet fails, help requested
Date: 9 Feb 1992 20:05:04 -0600
Organization: CS Dept, University of Texas at Austin


Can anyone help me to get SndStartFilePlay to work?  I found the
snippet below on ftp.apple.com.  I have modified it slightly to
compile under Think C 5.0.1 (4 byte ints used).  The call to
SndStartFilePlay always returns -108 (out of memory).  I have tried
lots of variations (including more memory), but nothing works.  I have
a Mac Plus running 7.0.

Thanks.

#include    <Resources.h>
#include    <Quickdraw.h>
#include    <Windows.h>
#include    <dialogs.h>
#include    <OSEvents.h>
#include    <Packages.h>
#include    <Sound.h>

#define    FALSE            0

main()
{
    Point                where = {20,20};
    OSErr                err;
    SFReply                reply;
    short                refnum;
    char*                string;

    InitGraf(&qd.thePort);
    FlushEvents(everyEvent, 0);
    InitWindows();
    InitDialogs(nil);
    InitCursor();

    string = (char*) "\pPick a SND File";

    SFGetFile (where, string, nil, -1, nil, nil, &reply);
    err = FSOpen(reply.fName, reply.vRefNum, &refnum);
    if (err != noErr) Debugger();

    err = SndStartFilePlay (nil, refnum, 0,74000, nil, nil, nil, FALSE);
    if (err != noErr) Debugger();

}
--
 ----
Peter Newton ([e-mail])



- -------------------------

From: [e-mail] (Peter Newton)
Subject:  SndStartFilePlay snippet fails, help requested
Date: 9 Feb 1992 23:53:38 -0600
Organization: CS Dept, University of Texas at Austin

> Can anyone help me to get SndStartFilePlay to work?  I found the
> snippet below on ftp.apple.com.  The call to SndStartFilePlay always
> returns -108 (out of memory).

I believe that I have located the problem myself.  Lurking in IM 6, I
see that the play-from-disk routines work only on machines that have
an "Apple Sound Chip."  I guess my Plus lacks one.  Might have to
replace the antique after all...
--
 ----
Peter Newton ([e-mail])



---------------------------

Subject: Classics And Double Buffered Sounds
From: [e-mail] (Russell Street)
Date: Mon, 10 Feb 1992 03:04:16 GMT
Organization: University of Auckland, New Zealand.

The double buffering of sound works on all types of Mac with
the new Sounds Manager (system 6.0.7 and later), doesn't it?
(i.e., regardless of the presence of the Sound Chip)

If yes, why can't I get the Double Buffering stuff to
go on a Classic, running System 7.0.1*?  The code I am
trying to use is the Double Buffer sample in the DTS
Snippets. It does work on a IIcx, however.

Any constructive help appreciated...
- ------------------------------------------------------------
Russell Street ([e-mail])
    It was the least I could do -- a quantity I specialize in.







---------------------------

From: [e-mail] (Tng Tai Hou)
Subject: Fast Graphics (Non-Quickdraw)
Date: 23 Jan 92 08:05:05 GMT
Organization: Institute of Systems Science, NUS, Singapore

After looking at many good and fast color Mac games, I have
come to the conclusion (no-surprise) that the bottleneck
to speed is Quickdraw.

Can anyone share experiences on implementing faster graphics
routines on the Mac? I suppose in writing these routines,
one has to forgo flexibility and just concentrate on, say,
256 colors only, and write superfast polygon fills and
CopyBits8 (for 256 colors) etc etc directly to screen.

I plan to write one package soon, but would like input
from the net.

I know good folks as Ben Haler (Solarian and LF) must have
written these. But since their livelihood depends on their
code and knowledge, it is understandable they can't share
their work. Unless a miracle happens and everyone is a
Richard Stallman.

Hope to hear from you soon. Please post responses to the
newsgroups.

Tai Hou
Singapore



- -------------------------

From: [e-mail] (Ben Haller)
Subject:  Fast Graphics (Non-Quickdraw)
Date: 23 Jan 92 15:08:14 GMT
Organization: Stick Software


  Before saying anything else, I would like to say this thread
should probably not be continued on comp.sys.mac.games, anyone
on that group interested in this subject should be reading programmer
already.  Please direct followups to comp.sys.mac.programmer
exclusively.

In article <[e-mail]>
   [e-mail] (Tng Tai Hou) writes:
>After looking at many good and fast color Mac games, I have
>come to the conclusion (no-surprise) that the bottleneck
>to speed is Quickdraw.
  It is *a* bottleneck.  Depending on the type of game, it isn't
*the* bottleneck.  For some games deciding on the moves for the
computer, or doing collision detection, etc., take much more time.
Even in arcade games (a surprising amount of time is spent on
collision detection in Lunatic Fringe).  Sound is also a bottleneck,
although it's one that it's harder to do anything about...

>Can anyone share experiences on implementing faster graphics
>routines on the Mac? I suppose in writing these routines,
>one has to forgo flexibility and just concentrate on, say,
>256 colors only, and write superfast polygon fills and
>CopyBits8 (for 256 colors) etc etc directly to screen.
  This is one approach.  Generality is not impossible; it's
just very very hard.  Limiting yourself to a single monitor
in 8 bit mode makes life a lot simpler.  A lot of programs
use 16 colors because you have to write half as many longwords
to get the same size graphic.

>I know good folks as Ben Haller (Solarian and LF) must have
>written these. But since their livelihood depends on their
>code and knowledge, it is understandable they can't share
>their work. Unless a miracle happens and everyone is a
>Richard Stallman.
  Not everyone is a Richard Stallman (not everyone *wants* to
be, either...) but I am quite willing to discuss direct-to-
screen techniques, I'm just not willing to provide any code.
I and others (Juri Munnki, other miscellaneous folks) often
discuss this sort of thing.  You might try looking for old
messages on subjects like direct-to-screen drawing, ShieldCursor,
and related topics.  I don't know if this group is archived
or not, but if it is that would be a good place to look for
old threads.
  If you have more specific questions, shoot.  It's hard to
address such a general question as "What all this about not
using QuickDraw then?" - narrow it down.

-Ben Haller ([e-mail])



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Fast Graphics (Non-Quickdraw)
Date: 23 Jan 92 16:22:55 GMT
Organization: Kalamazoo College

Ben Haller writes:
>
>You might try looking for old
>messages on subjects like direct-to-screen drawing, ShieldCursor,
>and related topics.
>

Would you mind expounding on ShieldCursor?

IM I-474 says "If [the cursor and the given rectangle] intersect,
ShieldCursor hides the cursor."

* Is it really the intersection of the cursor (its mask?) and the
rectangle, or does it only hide when the hot spot goes inside?

* You have to balance ShieldCursor with ShowCursor.  If you call
ShieldCursor more than once, on intersecting rectangles, does it work
appropriately?

* Does CopyBits watch for shielded cursors?  If you shield an area, then
call CopyBits on that area, does CopyBits know that it doesn't have to
hide and show the cursor?

* Why'd they do this silly thing with the offsetPt, instead of just
asking for the rectangle in global coordinates!?
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy



- -------------------------

From: [e-mail] (Tng Tai Hou)
Subject: Fast Graphics cont...
Date: 24 Jan 92 01:49:07 GMT
Organization: Institute of Systems Science, NUS, Singapore

Another mail I received ...
- ---
>From [e-mail] Thu Jan 23 23:46:55 1992
Subject:   Fast Graphics (Non-Quickdraw)
Status: RO

One thing about direct-to-screen; as soon as you start copying
"things" around (not single pixels) the overhead of using CopyBits
properly is very slim. CopyBits with no mask region, and same size
rects, and the same ctSeed for the source and destination pixMaps,
and WORD ALIGNMENT ! (Important !) of the pixMaps works very well
indeed. Longword alignment work even slightly better; and if
you happen to be on a '040 you could consider moving an aligned
cache row... (I get carried away :-)

Alignment and having the same ctSeed values is everything to
CopyBits, it can make the meek office slave into a roaring brute !
AND the best thing with CopyBits is that it's guaranteed to be
compatible with everything !

Sample code should not be needed; I gave you all the buzz words in
my previous mail ! Just arm yourself with Inside Mac I, V and VI,
as well as the TechNotes stack, and check out SysEnvirons (to check
for MMU) SwapMMUMode, 32-bit cleanliness, StripAddress, GetPixMap-
BaseAddress, PixMap32Bit, ... (and of course you would have to
check for 32bit QD versus classic QD as well)

ShieldCursor "signals" that an area has been modified; when you do
a direct transfer to screen, you should call ShieldCursor on the
area that's affected, followed by the transfer, followed by a
ShowCursor. This makes Pivots, SCSI screens, virtual screens, ...
work.

(Oh, and you'd have to understand about Graphics Devices and the
Color Manager as well, that's two more chapters, apart from the
Color QD chapter of IM V and the QD overview of IM IV) Maybe you
start realizing why there is no "fast" animation package for the
mac ? The truth is that CopyBits _IS_ as fast as it can be and
still be compatible.

                        / h+

- --

My response was:

I doubt very much if I want to be all-depth compatible. If I
write a game that runs in 8-bits, I will make sure that it
is either in that mode or it won't run. In which case writing
just for one mode ought to be faster than flexibility.

I have also been wondering 'bout double-buffering in terms
of switching pages. If the display cards behave as I
as think they ought to, maybe, just maybe, when turn
it to 4-bits, I can fool the card into believing it has
another buffer, and simply perform page-flips, instead
of zapping entire off-screens to the screen.

Think this is possible? The only card that actually has two video
pages is the good old Apple 8-bit Graphics card in 4-bits mode.


Thanks to Ben who has offered his help.



- -------------------------

From: [e-mail] (Christer Ericson)
Subject:  Fast Graphics cont...
Date: 26 Jan 92 13:55:43 GMT
Organization: Dep. of Info.Proc, Umea Univ., Sweden

In <[e-mail]> [e-mail] (Tng Tai Hou) writes:

>Another mail I received ...
>-----
>From [e-mail] Thu Jan 23 23:46:55 1992
>Subject: Re:  Fast Graphics (Non-Quickdraw)
>Status: RO

>One thing about direct-to-screen; as soon as you start copying
>"things" around (not single pixels) the overhead of using CopyBits
>properly is very slim. CopyBits with no mask region, and same size
>rects, and the same ctSeed for the source and destination pixMaps,
>and WORD ALIGNMENT ! (Important !) of the pixMaps works very well
>indeed. Longword alignment work even slightly better; and if
>you happen to be on a '040 you could consider moving an aligned
>cache row... (I get carried away :-)
> [...]
>(Oh, and you'd have to understand about Graphics Devices and the
>Color Manager as well, that's two more chapters, apart from the
>Color QD chapter of IM V and the QD overview of IM IV) Maybe you
>start realizing why there is no "fast" animation package for the
>mac ? The truth is that CopyBits _IS_ as fast as it can be and
>still be compatible.

The overhead of using CopyBits is not as slim as some people
might want us to think. One can help CopyBits considerably by
doing the things mentioned; having pre-shifted bitmaps (pixmaps)
avoiding clipping by giving an empty mask region and not drawing
into the current grafport. A big timesaver is to get the address
of CopyBits (or StdBits) and call it directly instead of going
through the dispatcher. This goes for all other traps that will
be called in the tightest loop as well. However, after doing
all this one will probably find that it still isn't fast enough.
In the tests that I and a friend of mine made, we could easily get
a 20% increase in performance by substituting CopyBits with our own
routine, which was far from optimal btw.

Furthermore, CopyBits is certainly _not_ as fast as it can be!
Obviously code could be unrolled forever to make a routine as fast
as possible, but to be fair it could be hard to fit lots of unrolled
code into ROM. However, there are many minor changes that could
have been made to the CopyBits code to make it run faster; here
are two examples:

>From the SE:

@1    MOVE.L    -2(A0),D0
    LSR.L    D5,D0
    MOVE.W    D0,(A1)+
    MOVE.L    (A0)+,D0
    LSR.L    D5,D0
    MOVE.W    D0,(A1)+
    DBRA    D1,@1

If the first MOVE.L -2(A0),D0 had been changed to MOVE.L (A2)+,D0
(or any other available address register) where A2 = A0 - 2, four
cycles would be saved each time through the loop. For a very
narrow bitmap this could be a loss (due to the setup of the
address register, depending on what the code surrounding this
code looks like -- I can't remember exactly), but for wider bitmaps
it's certainly a gain. So, four cycles aren't much someone says. Well,
for a 64x64 pixel bitmap that's a whopping 4096 cycles, which in
an animation sequence will eat up a lot of the CPU power on a
Mac SE/Plus.

>From the IIsi:

@1    AND.L    D5,D1
@2    BFEXTU    (A4){D6:32},D0
    ADDA.W    A0,A4
    EOR.L    D7,D0
    AND.L    D1,D0        ;All but the first and last time through
    NOT.L    D1        ;this loop, these four instructions will
    AND.L    (A5),D1        ;add upp to nothing but NOPs. The first
    OR.L    D1,D0        ;and last time, they clip the bitmap row.
    MOVE.L    D0,(A5)
    ADDA.W    A0,A5
    MOVEQ    #-1,D1
    SUBQ    #1,D2
    BGT    @2
    BEQ    @1
    BRA    foo

Someone must really think he was clever to come up with this, and
indeed he was. It is really clever in that it is extremely short
but on the other hand it's rather ineffective, and I for one
would rather have speed than cleverness. As can be seen from
inspection of the code it has been folded to handle all cases
of a bitmap row; the left end, the part in-between, and the
right end. By unrolling this code, the in-between part would look
something like

    ...
@2      BFEXTU  (A4){D6:32},D0
        ADDA.W  A0,A4
        EOR.L   D7,D0
        MOVE.L  D0,(A5)
        ...

Ignoring cache, this would save four instructions for a total gain
of 36 cycles for each long moved in the in-between phase.
In this latter case, since this rewrite would make the code twice
as large, and since there seems to be an abundance of similar
routines sprinkled liberally across the ROM I can somewhat
understand if Apple decided to go for size instead of speed, but
I still can't help thinking of how effective the code _could_
have been.

Now to be fair, CopyBits is extremely simple to use. It works on
all machines, it handles different bit depths, it can stretch
bitmaps, et cetera. In general, it'll do just fine. But it can't
be used for any animation other than for very few or small objects
(especially if your animation needs an erase cycle) unless you don't
care for how fast, or rather slow, your animation will be.
By all means, if CopyBits does what you want it to do, use it; just
remember that there are a few cases where it won't -- as Ben Haller,
Joe Holt and others will testify for.


Christer Ericson --- Internet: [e-mail] --- tel: [phone]
Department of Computer Science, University of Umea, S-90187 UMEA, SWEDEN



- -------------------------

From: [e-mail] (Steve Mariotti)
Subject:  Fast Graphics cont...
Date: 31 Jan 92 16:54:20 GMT
Organization: The University of Texas at Austin, Austin TX


>In <[e-mail]> [e-mail] (Tng Tai Hou) writes:
>
>>Another mail I received ...
>>-----
>>From [e-mail] Thu Jan 23 23:46:55 1992
>>Subject: Re:  Fast Graphics (Non-Quickdraw)
>>Status: RO
>
>>One thing about direct-to-screen; as soon as you start copying
>>"things" around (not single pixels) the overhead of using CopyBits
>>properly is very slim. CopyBits with no mask region, and same size
>>rects, and the same ctSeed for the source and destination pixMaps,
>>and WORD ALIGNMENT ! (Important !) of the pixMaps works very well
>>indeed. Longword alignment work even slightly better; and if
>>you happen to be on a '040 you could consider moving an aligned
>>cache row... (I get carried away :-)
>> [...]
>>(Oh, and you'd have to understand about Graphics Devices and the
>>Color Manager as well, that's two more chapters, apart from the
>>Color QD chapter of IM V and the QD overview of IM IV) Maybe you
>>start realizing why there is no "fast" animation package for the
>>mac ? The truth is that CopyBits _IS_ as fast as it can be and
>>still be compatible.

What about the possibility of doing something as un-IM-compliant as writing
directly to video memory?  I've tried this with a tight loop that does
nothing but fill an 8 bit screen with a single value (0xAA).  This is not
as instantaneous as I thought!  In fact, it seems that doing a CopyBits of
a 640x480 image onto the screen is distinctly faster.  This doesn't seem
that it should be the case.  This was on a machine with a NuBus video card.

Is there something that must be done to set up Nubus for big transfer of
data that will speed writes across NuBus beyond CopyBits levels?  I ache
to have some fast (very fast) graphics routines in my library.  Of course
these routines will be current-machine dependent and may not work on
future models of Macintosh, but my concern is only with current Mac models.

Ideally, one would be able to circumvent all ToolBox and ColorQuickDraw
routines, and simply use video memory and the video card's CLUT to do the
animation.  This should be lightning fast, and would allow the Mac to offer
things like multiple sprite planes, multi-layer scrolling, etc etc.  There's
no reason why a lightning fast game couldn't be designed for the Macintosh,
but it seems one would have to get around most of Apple's ROM code for
graphics to do so.

While this is very ugly and I'm a heretic for suggesting it, it is nonetheless
attractive to me.

Has anyone had any success in doing things along these lines?

Bill Budge (of RasterBlaster and Pinball Construction Set for the Apple II
fame) commented when he first got his Mac 128 (it was a re-release model
held together entirely by plexiglass and sporting only an external drive) that
if the Macintosh were ever to support technologically hip game software, it
would require the use of custom graphics routines.  This was back when there
was no Color Quickdraw, and only 8Mhz 68000's, but he recognized this very
early on.

No doubt for Color QuickDraw this still holds, especially on 16Mhz color
machines.

Anyone else out there yearn for what could be called "FrankenDraw"?

respectfully,

Steve
[e-mail]



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Fast Graphics cont...
Date: 31 Jan 92 20:57:04 GMT
Organization: Kalamazoo College

In article <[e-mail]> [e-mail] (Steve Mariotti) writes:
>
>What about the possibility of doing something as un-IM-compliant as writing
>directly to video memory?
>

Here's as good a place to trumpet something that everyone should know.
When you write directly to the screen, surround the calls with a
ShieldCursor and a ShowCursor.  This lets some third-party monitors
(like the Radius Color Pivot) know that you're messing with that area.
If you do not do this, these monitors will keep your data in a virtual
screen and not display it until later.

Because all QuickDraw routines call ShieldCursor and ShowCursor, the
card designers figured they could patch those calls to let the monitor
know when it has to update the actual screen.  Unfortunately, very few
people seem to know about it...

Meanwhile...

>I've tried this with a tight loop that does
>nothing but fill an 8 bit screen with a single value (0xAA).  This is not
>as instantaneous as I thought!  In fact, it seems that doing a CopyBits of
>a 640x480 image onto the screen is distinctly faster.  This doesn't seem
>that it should be the case.

Possibly you're writing all the values that don't show on the screen?
(right-left) != rowBytes, you know.

>Ideally, one would be able to circumvent all ToolBox and ColorQuickDraw
>routines, and simply use video memory and the video card's CLUT to do the
>animation.  This should be lightning fast, and would allow the Mac to offer
>things like multiple sprite planes, multi-layer scrolling, etc etc.  There's
>no reason why a lightning fast game couldn't be designed for the Macintosh,
>but it seems one would have to get around most of Apple's ROM code for
>graphics to do so.

I don't think so.  Things like sprites and scrolling backgrounds are
built into hardware; they have custom chips.  I don't believe any video
card made for the Mac has any such thing available.  You'd still have to
rely on the 680x0 to push the bits to the video memory.

Most existing video games don't use QuickDraw.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Michael Kohne)
Subject:  Fast Graphics cont...
Date: 1 Feb 92 15:07:11 GMT
Organization: University of Maryland Baltimore Campus, Computer Science Department

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>Here's as good a place to trumpet something that everyone should know.
>When you write directly to the screen, surround the calls with a
>ShieldCursor and a ShowCursor.  This lets some third-party monitors
>(like the Radius Color Pivot) know that you're messing with that area.
>If you do not do this, these monitors will keep your data in a virtual
>screen and not display it until later.
>
>Because all QuickDraw routines call ShieldCursor and ShowCursor, the
>card designers figured they could patch those calls to let the monitor
>know when it has to update the actual screen.  Unfortunately, very few
>people seem to know about it...
>
You know, I saw Ben Haller's post on this subject, and inserted Shileld and
ShowCursor calls into my init ClickShow. Now, I've gotten some wierd results.
Ocassionally, when I click, I'll get an imprint of the cursor on the screen.
this usually happens when clicking buttons and the like. Any ideas as to
what could be going on? (Note the my direct-to-screen drawing is done from a
postevent patch.) I'm wondering if ShieldCursor is cumulative (if I call it
twice with 2 different rectangles, does the second over-ride the first?)



--
"Pope" Q.E.D         Lord High Jabberwocky
Michael Kohne        [e-mail]
Coded Message: FIME NDUXXMS MZP FTQ EXUFTK FAHQE SKDQ MZP SUYNXQ UZ FTQ IMNQ.



- -------------------------

From: [e-mail]
Subject:  Fast Graphics cont...
Date: 2 Feb 92 04:57:38 GMT
Organization: University of Kansas Academic Computing Services

>>I've tried this with a tight loop that does
>>nothing but fill an 8 bit screen with a single value (0xAA).  This is not
>>as instantaneous as I thought!  In fact, it seems that doing a CopyBits of
>>a 640x480 image onto the screen is distinctly faster.  This doesn't seem
>>that it should be the case.
>
> Possibly you're writing all the values that don't show on the screen?
> (right-left) != rowBytes, you know.

You're also moving a byte at a time.  Try the loop with 0xAAAAAAAA.

john calhoun-



- -------------------------

From: [e-mail] (Amanda Walker)
Subject:  Fast Graphics cont...
Date: 3 Feb 92 15:09:25 GMT
Organization: Visix Software Inc., Reston, VA

[e-mail] writes:
> You're also moving a byte at a time.  Try the loop with 0xAAAAAAAA.

Or even better, load up 6 data registers with 0xAAAAAAAA and do
MOVEM.L inside a DBRA loop (on anything greater than a 68000, this will
run completely out of the instruction cache, giving you the maximum
possible transfer rate).


Amanda Walker                              [e-mail]
Visix Software Inc.                    ...!uunet!visix!amanda
--
"This is a one line proof...if we start sufficiently far to the left."
        --- [e-mail]



- -------------------------

From: [e-mail] (Lloyd Lim)
Subject:  Fast Graphics cont...
Date: 4 Feb 92 01:12:46 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>Here's as good a place to trumpet something that everyone should know.
>When you write directly to the screen, surround the calls with a
>ShieldCursor and a ShowCursor.  This lets some third-party monitors
>(like the Radius Color Pivot) know that you're messing with that area.
>If you do not do this, these monitors will keep your data in a virtual
>screen and not display it until later.

I'm also trying to do this and having problems.  No matter what rect I use
ShieldCursor shields a rect approximately (0,0,550,350).  I use rects in
global coordinates with an offset of (0,0).  This is with System 6.0.5,
an Apple 13" RGB, and no INITs.

Any idea what's the probably stupid mistake I'm making?  It wouldn't matter
if a dialog is on the screen, would it?

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616



- -------------------------

From: [e-mail] (Joakim Greben|)
Subject: Fast graphics...
Date: 9 Feb 92 20:09:28 GMT
Organization: UDAC, Uppsala, Sweden

Some month ago there was a discussion about drawing directly
to the screen. As a final result someone posted a routine in C that
did it in 8 bits color. I thought that I saved the source - but tough luck!
I would appreciate if someone reposted the source for me (thank you!)
- -
Joakim Greben| at ICU in Sweden
[e-mail]
- -



---------------------------

End of C.S.M.P. Digest
**********************